Method:
<p>
	Make an XMLHttpRequest to the server for XML encoded rows of data and then
	transform it by loading another XML document (an XSLT style sheet) for the
	built-in transformation engine to use. The overhead of an extra request is
	non-trivial for small data sets where the extra time may dwarf the
	transformation time itself.
</p>
<p>
	The transformation step forks based on browser. On IE it's possible to
	transform the document to a string which is then injected using innerHTML.
	On other browsers the document is transformed into a DOM DocumentFragment
	which is then re-parented into the page since the XSLTProcessor class does
	not provide a simple "transform to string" API.
</p>
Results:
<p>
	XML is piggy, but by offloading the XSLT transform onto native code, we can
	perhaps do better than script-based transformations...right?
</p>
<p>
	Ish.
</p>
<p>
	For large numbers of rows, offloading the overhead of client transformation
	to native code shows dramatic speed gains. For instance, in Firefox 3.0 the
	total time to transform 5000 rows via XSLT is roughly half that of the same
	transform done in script. As scripting engines get faster, this delta may
	close, but XSLT is likely to remain competitive.
</p>
<p>
	At lower row counts the inherent disadvantages of loading data in XML and
	pulling in a separate style sheet begin to show. In tests with 500 rows
	XSLT still maintains a slight edge over JSON but the advantage is minimal
	and neither are quite as fast as server-generated HTML.
</p>
<p>
	If your data is already in XML, you have a lot of it, and need to transform
	it to a static rendering then XSLT can't be beat. But you'll need to learn
	XSLT. Oof.
</p>
